为什么微服务需要 API 网关？

0. 引言

微服务拆分后，客户端直接调用每个服务会面临：入口散乱（每个服务都要处理鉴权/限流/跨域）、协议不一（RPC/HTTP 混杂）、无法统一治理（灰度、监控、安全）。API 网关作为所有流量的统一入口，把横切关注点（Cross-cutting Concerns）从业务服务中剥离。本文梳理网关的职责、架构位置与主流实现。

1. 网关在架构中的位置

图表渲染中…

客户端只认识网关一个地址；网关按路径/域名路由到具体服务；
网关通过注册中心动态感知后端实例变化，无需人工维护路由表。

2. 网关的核心职责

职责	说明	典型实现
路由转发	按 URL/Header 分发到服务，支持重写、聚合	核心能力，所有网关都有
认证鉴权	统一校验 JWT/OAuth2/API Key，防越权	接入认证中心
限流熔断	全局限流、按用户/接口限流，保护后端	令牌桶/滑动窗口/熔断器
灰度发布	按 Header/Cookie/权重路由到新版本	灰度标签 + 路由规则
协议转换	HTTP ↔ RPC、gRPC ↔ REST	降级到内部 Dubbo 协议
安全防护	IP 黑白名单、WAF、防爬	接入安全组件
可观测	统一日志、监控、链路追踪切片	与 APM 集成

设计原则：网关只做"通用横切"，不做业务逻辑——业务规则下沉到服务层，否则网关会变成"上帝服务"（monolith gateway）。

3. 主流网关对比

网关	类型	性能	生态	适用
Kong	Nginx + Lua（OpenResty）	高	插件丰富（500+）	通用 API 管理、多语言
Apache APISIX	Nginx + Lua，云原生	高	插件热更新、K8s 集成好	云原生、国产化
Spring Cloud Gateway	Java（WebFlux 响应式）	中	Spring 生态无缝	Java/Spring Cloud 技术栈
Nginx Ingress / Envoy	七层代理 / 数据面	高	K8s 原生	K8s 集群入口
自研网关	定制	可控	成本高	大厂强定制场景

网关 vs 负载均衡（Nginx/LVS）：负载均衡解决"流量分发到哪台机器"（L4/L7 转发）；网关在此基础上叠加"协议转换、鉴权、限流、灰度"等API 治理能力。实践中常组合：LVS → Nginx → 网关 → 服务。

4. 网关的典型设计模式

4.1 统一入口 + 路由

text

/app/orders/**        → 订单服务
/app/users/**         → 用户服务
/admin/**             → 管理后台（额外鉴权）
/api/v1/**            → 对外 OpenAPI（限流 + API Key）

4.2 灰度发布

text

Header: X-Canary: true → 路由到 新版本（v2）
无 Header / false      → 路由到 稳定版（v1）

先 1% 流量试运行，逐步放量，异常即回滚——网关是灰度发布的最佳落点。

4.3 限流

text

按用户 ID / IP / 接口维度限流（令牌桶）
超限 → 429 或排队降级

5. 网关的高可用设计

无状态部署：网关自身不存业务状态（JWT 无状态鉴权），可水平扩展；
多活部署：多机房多套网关，DNS/全局负载均衡接入；
降级策略：网关故障时提供"兜底页面/缓存响应"，避免雪崩；
性能：网关是全站流量的必经之路，必须低开销（异步 IO、连接池复用），避免成为瓶颈。

6. 小结

网关解决入口统一与横切治理：路由、鉴权、限流、灰度、可观测；
选型：Java 技术栈用 Spring Cloud Gateway；云原生/高性能用 APISIX/Kong；
网关不做业务逻辑，只做通用能力；自身必须无状态、可扩展、高可用；
分层：LVS/Nginx（接入层）→ 网关（治理层）→ 业务服务。

下一章讲解服务注册与发现：注册中心原理与 Nacos/Eureka/ZooKeeper 的 CP/AP 之争。